has this always been the case or have we implicitly been assuming read.len() == write.len()? and is this sensible to represent for more complex implementors (ie. using DMA, linux)?

we have Transactional for building sequences, if you need to do varying length things, it would seem to me to be simpler (or maybe, less surprising to demand the same lengths here?

have we implicitly been assuming read.len() == write.len()?

Before this PR, only the single-buffer Transfer (now TransferInplace) existed. Single-buffer already enforced read len = write len.

The idea for the runs for max(read.len(), write.len()) comes from the nRF SPI DMA, which automatically does this. It's somewhat handy, for example to do "write command byte, read big data" you can make the write buf small (1 byte) and only need memory for a big read buf (1 + N bytes).

I agree it's not that useful if we have TransferInplace or Transactional, and it could be annoying to support using stm32 DMA for example...

If we require same-length for both bufs, do we mandate that impls panic on length mismatch, or return an error?

This was discussed in today's REWG meeting. TLDR: seems people are OK with differing lengths.

Also the possibility of allowing impls to support it or not was discussed, but IMO it defeats the point since drivers wouldn't be able to use it.